This invention relates to computer compilers for modular programming languages and more particularly to a compiler that allows module interfaces to be read automatically.
A programming technique known as "modular programming" was proposed more than ten years ago in order to cope with growing software developments in scale (Parnas, D. "A technique for software module specification", Comm.ACM 15, 5 (May 1972), pp330-336). Languages such as Ada and Modula-2 have a syntax that positively supports such programming.
Even in programming in C language, which lacks any such syntactical support, coding in modular programming style is widely put into practice. By this technique, programs are composed of a group of modules. One module is an aggregate of logically associated data and functions, which is defined by an interface and implementation. The former determines how to use a module, whereas the latter represents how to implement a module.
The most notable feature of modular programming lies in the restrictive interrelation of modules. That is, any module, M, discloses only its interface to other modules to make use of M (clients of M), but the implementation of M is completely concealed from any such clients. This makes it possible to proceed with program development while localizing the influence on the entire program of a modification in some part of a program. Thus it becomes possible to make modifications in implementation independently of clients.
In such modular programming, however, it is necessary to read in advance an interface with module M when a client of module M is compiled. Specification of such reading varies from language to language, yet it is at any rate left to a programmer's manual work. For example, a module using three modules, Symbol, String, and List would in Ada begin with the following three "with clauses":
with Symbol;
with String;
with List, and would in C or C++ begin with the following three # include instructions respectively:
#include "Symbol.h"
#include "String.h"
#include "List.h"
Yet, in this instance, the interface with the module "Symbol" is assumed to be in a file, Symbol.h.
Such explicit management of "reading" by a programmer is more complicated in an object-oriented language. That is, with object-oriented languages, there exist semisequential relations between modules ascribed to "inheritance" and therefore the module reading sequence also has to follow the semisequential relations.
During development of a program, a module group that a module uses at certain times may change frequently. A programmer is requested to arrange with-clauses or # include instructions in proper sequence without creating inconsistencies in spite of such frequent change. This may significantly impair the productivity of software.